Early computer systems, including personal computers ("PCs"), employed a character-based display interface wherein a standard set of characters was defined in firmware or hardware for the computer system. To display one of the set of characters, a code corresponding to the character to be displayed was transmitted from the computer system's central processing unit ("CPU") to, most typically, video random access memory ("VRAM") upon which the display was mapped. Character-based displays were relatively efficient in terms of CPU bandwidth required, but were also inflexible in that the character set limited their display capabilities.
In response to this inflexibility and in an attempt to define a new paradigm for displaying information on a computer display, Xerox.RTM. developed a graphical user interface ("GUI") environment employing software-configurable bit-mapped graphical images rather than a firmware or hardware-defined set of characters to display information. The GUI environment also typically employs a mouse or other pointing device to allow a user to point, click or click and drag icons or other symbols about the display to signify operations to be undertaken by the computer system. This is in lieu of previous character-based command-driven interfaces.
Of perhaps even more moment, the GUI environment introduced the concept of "windows" wherein the computer system can display data corresponding to several application tasks at once. The data pertaining to each application task is contained in an associated movable, sizable window covering a region that is all or only a portion of the entire area of the display. Windows can overlap and occlude one another, much the way papers overlap and occlude one another on a desktop.
Conventionally, one window (an "active window") overlaps all others ("inactive windows"). The active window contains data pertaining to an application task executing in the foreground. By clicking on an inactive window, a user can cause the inactive window to come to the fore visually and can cause execution of the corresponding application task to move to the foreground.
Other computer manufacturers have adopted the GUI environment paradigm in operating systems for PCs. Apple.RTM. developed a GUI operating system for the Lisa.RTM. and the Macintosh.RTM.--Microsoft.RTM. developed Windows.RTM. for IBM-compatible PCs. IBM.RTM. itself developed OS/2.RTM., also for IBM-compatible PCs. These new GUI operating systems have proven to be powerful and popular, particularly among computer users who are unfamiliar or uncomfortable with more traditional command-driven interfaces.
As stated above, the active window overlaps inactive windows. A user has complete access to functions of the application task corresponding to the active window. To access functions of an application task contained in any one of the inactive windows, the user is forced to make the desired application task's inactive window active before accessing any of the functions therein. Once having accessed those functions, the user must then reactivate the previous active window to return to the original application task.
For example, if a user is working in a word processor application task, the word processor is displayed in an active window. If the user wants to access a separate database manager application task, the user must activate the database manager application task, thereby moving the word processor application task to the background. To return to the word processor application task, the user must manually activate the then inactive window corresponding to the word processor application task by clicking in the word processor application task's window. The user must therefore undergo several operation to access functions of a few different tasks.
The above disadvantage is particularly acute for users who bill their professional time to clients. Timekeeping application tasks that allow a user to measure and record time spent on a given project have become popular among such users. However, with existing timekeeping application tasks, the user must activate a window corresponding to the timekeeping application task to establish, start or stop timers. This interrupts the previous application task with which the user was interacting. The user must manually reactivate the previous application task to return to the point at which the user was prior to activating the timekeeping application task. When the user reactivates the previous application task, the window corresponding thereto moves to the fore, perhaps occluding the window corresponding to the timekeeping application task and obscuring the timekeeping application task's timer displays.
Accordingly, what is needed in the art is an application task wherein functions of the application task can be accessed without inactivating the currently active window and wherein execution automatically returns to the currently active window once one of the functions of the application task has been accessed, thereby allowing a user continued access to the currently active window.